How could we validate this coverage? At the moment this seems static, meaning it must be updated each time by some unknown force. If you have a reproducible method which updates this, consider documenting it under contributing.md. Otherwise, consider removing it altogether because part of code coverage is about building trust and reproducibility (which we directly collide with if we supply a measurement without any validation). A side effect of doing this is that it should increase development velocity by making it impossible to avoid an update if coverage changes.

What happened to 4d arrays?

Consider using Pydantic to help define classes which may be used for validation broadly. You could also likely incorporate Pandera, if DataFrames are to be included somehow, which integrates nicely with Pydantic. Doing this will save you effort from building bespoke data / contract validation tooling.

As you go through this effort you can use concepts from object-orientated programming (OOP) to help you modulate what is being validated and worked on at an atomic level within the software. For instance, what do these attributes pertain to - maybe it's "widget_x"? You can label it as such, using defined objects which are both validated and also passed by type to other portions of the software. You might eventually find that you also want "widget_y" with separate attributes too. Keep separation of concerns in mind and at the same time, avoid over-specific OOP ("super good enough" is often best).

I strongly encourage greater specificity here with concern to "what kind" of contract, now that you're building this out. Specifically, Design by contract, Hoare Triples, and Abstract Data Typing come to mind.

I'm unsure if this comes into play here exactly, but this came to mind: Consider using beartype to help validate objects at time of use.

This looks like an antipattern which arose from how things are executed for tests. Consider finding a way to remove this code. Sometimes adding an __init__.py file can help, but it depends on what happened that made you add this in (I can't tell from just the code). Pytest can sometimes be a bit cranky about internal imports unless you explicitly tell it that the the test dir is a package with the init file.

Consider avoiding this bespoke commenting pattern and instead using docstrings inside the fixture definition. Comment applies wherever this pattern popped up.

Consider using pytest's parametrize to collapse the code needed for repeated iteration over similar data. Comment applies to many tests in this pr.

The r here looks like a typo. Consider removing.

I couldn't tell exactly, but is pyarrow needed for this PR?